home *** CD-ROM | disk | FTP | other *** search
/ Tricks of the Mac Game Programming Gurus / TricksOfTheMacGameProgrammingGurus.iso / Information / CSMP Digest / volume 1 / csmp-v1-184.txt < prev    next >
Encoding:
Text File  |  1994-12-08  |  43.0 KB  |  1,145 lines  |  [TEXT/R*ch]

  1. C.S.M.P. Digest             Thu, 15 Oct 92       Volume 1 : Issue 184
  2.  
  3. Today's Topics:
  4.  
  5.     System Extension sample source wanted!!
  6.     PLstrcmp?? Do the right thing!
  7.     IM 1-7  vs New: FILES, PROCESSES, MEMORY Books
  8.     STUFFIT FORMAT
  9.     Problem writing INIT/cdev
  10.     A/ROSE
  11.     Best text compression?
  12.     How do you launch a Control Panel?
  13.     Top byte of 24-bit offscreen gworld?
  14.  
  15.  
  16.  
  17. The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.
  18.  
  19. The digest is a collection of article threads from the internet newsgroup
  20. comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
  21. regularly and want an archive of the discussions.  If you don't know what a
  22. newsgroup is, you probably don't have access to it.  Ask your systems
  23. administrator(s) for details.  (This means you can't post questions to the
  24. digest.)
  25.  
  26. Each issue of the digest contains one or more sets of articles (called
  27. threads), with each set corresponding to a 'discussion' of a particular
  28. subject.  The articles are not edited; all articles included in this digest
  29. are in their original posted form (as received by our news server at
  30. cs.uoregon.edu).  Article threads are not added to the digest until the last
  31. article added to the thread is at least one month old (this is to ensure that
  32. the thread is dead before adding it to the digest).  Article threads that
  33. consist of only one message are generally not included in the digest.
  34.  
  35. The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
  36. [128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
  37. file /pub/mac/csmp-digest/README before downloading any files.  The most
  38. recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
  39. directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
  40. archive has a mail server; send a message with the text '$MACarch help' (no
  41. quotes) to LISTSERV@ricevm1.rice.edu for more information.
  42.  
  43. The digest is also available via email.  Just send a note saying that you
  44. want to be on the digest mailing list to mkelly@cs.uoregon.edu, and you will
  45. automatically receive each new issue as it is created.  Sorry, back issues
  46. are not available through the mailing list.
  47.  
  48. Send administrative mail to mkelly@cs.uoregon.edu.
  49.  
  50.  
  51. -------------------------------------------------------
  52.  
  53. From: Minh Lang <minh@inst-sun1.jpl.nasa.gov>
  54. Subject: System Extension sample source wanted!!
  55. Organization: Jet propulsion Laboratory
  56. Date: Tue, 28 Jul 1992 15:43:57 GMT
  57.  
  58. I am looking for some sample source for writing System Extension.
  59. I would appreciate any pointer or info (ftp sites, books etc...).
  60. Thanks.
  61.  == Minh ==
  62.  
  63. +++++++++++++++++++++++++++
  64.  
  65. From: ins712r@aurora.cc.monash.edu.au (Heng Chiang)
  66. Organization: Monash University
  67. Date: Wed, 29 Jul 1992 05:03:58 GMT
  68.  
  69. minh@inst-sun1.jpl.nasa.gov (Minh Lang) writes:
  70. : I am looking for some sample source for writing System Extension.
  71. : I would appreciate any pointer or info (ftp sites, books etc...).
  72. : Thanks.
  73. :  == Minh ==
  74.  
  75. Me TOO!  I have found a lot of source code for general applications
  76. but I haven't seen any for control panels / extensions.  I would
  77. really like to know how people actually start writing extensions (INIT)
  78. with the horrible lack of documentation.
  79.   I would rather prefer email, because I generally do not check this
  80. particular group.  Thanks!
  81.  
  82.     Heng.
  83.  
  84. - --
  85. Heng Chiang                    Internet: ins712r@lindblat.cc.monash.edu.au
  86. STRESS - The confusion created when      ins712r@aurora.cc.monash.edu.au
  87. the mind overrides the body's urge       dgentley@yoyo.cc.monash.edu.au
  88. to choke the living daylight out of          RULE 1 - The female is always
  89. some deserving people. - Unknown                      *right*?  - Somebody
  90.  
  91. +++++++++++++++++++++++++++
  92.  
  93. From: haynes@mace.cc.purdue.edu (Carl W. Haynes III)
  94. Date: 29 Jul 92 09:11:58 GMT
  95. Organization: Purdue University
  96.  
  97. In article <1992Jul29.050358.4513@monu6.cc.monash.edu.au> ins712r@aurora.cc.monash.edu.au (Heng Chiang) writes:
  98. >minh@inst-sun1.jpl.nasa.gov (Minh Lang) writes:
  99. >: I am looking for some sample source for writing System Extension.
  100. >Me TOO!  I have found a lot of source code for general applications
  101. >but I haven't seen any for control panels / extensions.  I would
  102. >really like to know how people actually start writing extensions (INIT)
  103. >with the horrible lack of documentation.
  104.  
  105. The best piece of documentation I've seen on writing INITs was an article
  106. by Eric Shapiro that I pulled off of AOL called "Writing INITs in Think C".
  107. I'm not sure if it's available in any of the archives. If you can't find
  108. it and don't have access to AOL let me know and I'll e-mail a copy to
  109. any one who wants it. This article has the best INIT shell I've seen.
  110.  
  111. The second edition of Macintosh Programming Secrets also has info on writing
  112. inits, including patching traps. I personally think that someone should write
  113. a whole book on low-level stuff like drivers and inits.
  114.  
  115. If your interested in communications, Programming with AppleTalk has an
  116. example of an INIT.
  117.  
  118. The Macintosh C Programming Primer Vol II has an example of an INIT,
  119. although it does not patch any traps which is usually what you want to
  120. do when you write an INIT. However, it has a good example of a cdev.
  121.  
  122. Personally, I learned how to write INITs by deciding on something that I
  123. wanted to do and posting lots of questions. Like most aspects of Mac 
  124. programming, writing INIT's has a pretty steep learning curve, but the
  125. rewards definately are worth the effort.
  126.  
  127. - --
  128. Carl W. Haynes III  
  129. Haynes Consulting Services        ||  CWH3@aol.com
  130. PO Box 2715                       ||  haynes@mace.cc.purdue.edu
  131. W. Lafayette, IN 47906            ||  hcs@applelink.apple.com
  132. - ----------------------------------------------------------------------
  133.      Macintosh Programming & Consulting -- I am currently seeking 
  134.         Macintosh development contracts, available immediately.
  135.  
  136. +++++++++++++++++++++++++++
  137.  
  138. From: peirce@outpost.SF-Bay.org (Michael Peirce)
  139. Date: 29 Jul 92 17:01:54 GMT
  140. Organization: Peirce Software
  141.  
  142.  
  143. In article <1992Jul29.050358.4513@monu6.cc.monash.edu.au> (comp.sys.mac.programmer), ins712r@aurora.cc.monash.edu.au (Heng Chiang) writes:
  144. > minh@inst-sun1.jpl.nasa.gov (Minh Lang) writes:
  145. > : I am looking for some sample source for writing System Extension.
  146. > : I would appreciate any pointer or info (ftp sites, books etc...).
  147. > : Thanks.
  148. > :  == Minh ==
  149. > Me TOO!  I have found a lot of source code for general applications
  150. > but I haven't seen any for control panels / extensions.  I would
  151. > really like to know how people actually start writing extensions (INIT)
  152. > with the horrible lack of documentation.
  153.  
  154. The book "Programming with AppleTalk" from Addison-Wesley (and
  155. written by me) has a complete RDEV/INIT example.  This is a
  156. Chooser interface (the RDEV part) as well as an INIT that
  157. installs some code into the system heap (to listen to an
  158. AppleTalk socket).
  159.  
  160. - --  Michael Peirce      --   peirce@outpost.SF-Bay.org
  161. - --  Peirce Software     --   Suite 301, 719 Hibiscus Place
  162. - --                      --   San Jose, California USA 95117
  163. - --  Makers of...        --   voice: (408) 244-6554 fax: (408) 244-6882
  164. - --            SMOOTHIE  --   AppleLink: peirce & America Online: AFC Peirce
  165.  
  166. +++++++++++++++++++++++++++
  167.  
  168. From: keith@taligent.com (Keith Rollin)
  169. Date: 31 Jul 92 07:03:17 GMT
  170. Organization: Taligent
  171.  
  172. In article <55395@mentor.cc.purdue.edu>, haynes@mace.cc.purdue.edu (Carl W.
  173. Haynes III) writes:
  174. >
  175. > The second edition of Macintosh Programming Secrets also has info on writing
  176. > inits, including patching traps. I personally think that someone should write
  177. > a whole book on low-level stuff like drivers and inits.
  178.  
  179. Me, too...   :-)
  180.  
  181. - --
  182. Keith Rollin
  183. Phantom Programmer
  184. Taligent, Inc.
  185.  
  186. ---------------------------
  187.  
  188. From: jpurlia@qualcomm.com (John Purlia)
  189. Subject: PLstrcmp?? Do the right thing!
  190. Date: 28 Jul 92 21:51:57 GMT
  191. Organization: Qualcomm, Inc.
  192.  
  193. Has anyone else noticed the effective weirdness of PLstrcmp in MPW?  I'm
  194. using qsort to sort a list of pascal style strings in ascending alphabetic
  195. order.  My comparison function basically uses a PLstrcmp to test equality
  196. of the list elements.  Here's the weird part:  PLstrcmp thinks that "Public
  197. Folder" comes before "Public".  If I take the same data, convert each
  198. element to C style using p2cstr, and use strcmp in my comparison function,
  199. "Public" comes before "Public Folder" just as you would expect.
  200.  
  201. Is there a known bug in PLstrcmp (MPW 3.2) or for that matter any of the
  202. other Pascal style string routines?  Is there a fix or am I going to have
  203. to do the convert to C conversion all over the place?  (No, the toolbox
  204. routine I'm using to get the data does not have a C string equivalent.)
  205.  
  206. ...........................................................................
  207. John Purlia          : My brain; not my company's brain.  My brain says...
  208. jpurlia@qualcomm.com :      "Just about any movie could be made better
  209. AppleLink:  AM0470   :       if one of the characters were a vampire."
  210. ...........................................................................
  211.  
  212. +++++++++++++++++++++++++++
  213.  
  214. From: keith@taligent.com (Keith Rollin)
  215. Date: 29 Jul 92 08:33:41 GMT
  216. Organization: Taligent
  217.  
  218. In article <jpurlia-280792143857@129.46.5.45>, jpurlia@qualcomm.com (John
  219. Purlia) writes:
  220. > Has anyone else noticed the effective weirdness of PLstrcmp in MPW?  I'm
  221. > using qsort to sort a list of pascal style strings in ascending alphabetic
  222. > order.  My comparison function basically uses a PLstrcmp to test equality
  223. > of the list elements.  Here's the weird part:  PLstrcmp thinks that "Public
  224. > Folder" comes before "Public".  If I take the same data, convert each
  225. > element to C style using p2cstr, and use strcmp in my comparison function,
  226. > "Public" comes before "Public Folder" just as you would expect.
  227. > Is there a known bug in PLstrcmp (MPW 3.2) or for that matter any of the
  228. > other Pascal style string routines?  Is there a fix or am I going to have
  229. > to do the convert to C conversion all over the place?  (No, the toolbox
  230. > routine I'm using to get the data does not have a C string equivalent.)
  231.  
  232. I don't know about PLstrcmp. If I were in your position, I'd do one of two
  233. things:
  234.  
  235. - - Disassemble PLstrcmp and see WTF was going on.
  236. - - Use one of the toolbox routines that compares Pascal strings (RelString,
  237. EqualString, IUCompString, IUMagString, IUEqualString, or IUMagIDString). Here
  238. are some notes I have on the functions (I can never keep them straight!):
  239.  
  240.     Name            Takes   Case    Diac    Returns         Trap used
  241.     --------------  ------- -----   -----   ------------    ----------
  242.     RelString:      Str255  spec    spec    -1, 0, 1        _RelString
  243.     EqualString:    Str255  spec    spec    Boolean         _CmpString
  244.  
  245.     IUCompString:   Str255  TRUE    TRUE    -1, 0, 1        _Pack6,#10
  246.     IUMagString:    Ptr/len TRUE    TRUE    -1, 0, 1        _Pack6,#10
  247.  
  248.     IUEqualString:  Str255  FALSE   FALSE   Inv. Boolean    _Pack6,#12
  249.     IUMagIDString:  Ptr/len FALSE   FALSE   Inv. Boolean    _Pack6,#12
  250.  
  251. The Case and Diac columns refer to whether or not the functions are sensitive to
  252. case or diacriticals. "spec" means that you can specify whether they are or not.
  253.  
  254. - --
  255. Keith Rollin
  256. Phantom Programmer
  257. Taligent, Inc.
  258.  
  259. ---------------------------
  260.  
  261. From: 21602MR@MSU (Mark Rosenberg)
  262. Subject: IM 1-7  vs New: FILES, PROCESSES, MEMORY Books
  263. Date: 26 Aug 92 14:48:45 GMT
  264. Organization: Michigan State University
  265.  
  266. I am jumping into programming the MAC - All sources say I need IM 1, and
  267. a few other IM vols, But Addison Wesley has come out with 3 new books:
  268. Files, Processes, and Memory which replace the original IM books??
  269. Do I STILL need to get IM v1 (with references to 128k MACs and LISA)
  270. or should I get one or all of the New books??
  271. Thanks in advance... Please respond to the net!
  272. Mark Sartor (via Mark Rosenbergs account)
  273.  
  274. +++++++++++++++++++++++++++
  275.  
  276. From: keith@taligent.com (Keith Rollin)
  277. Date: 26 Aug 92 20:12:10 GMT
  278. Organization: Taligent
  279.  
  280. In article <1992Aug26.145249.19654@msuinfo.cl.msu.edu>, 21602MR@MSU (Mark
  281. Rosenberg) writes:
  282. > I am jumping into programming the MAC - All sources say I need IM 1, and
  283. > a few other IM vols, But Addison Wesley has come out with 3 new books:
  284. > Files, Processes, and Memory which replace the original IM books??
  285. > Do I STILL need to get IM v1 (with references to 128k MACs and LISA)
  286. > or should I get one or all of the New books??
  287.  
  288. If you can wait (and have the bucks), I'd suggest getting the new books. As
  289. you've seen, there are three now, and probably about 12 more in the wings. The
  290. whole new suite is intended to replace the old IM I-VI, as well as many of the
  291. technotes and sample code that DTS puts out. They are chock full of samples, and
  292. include a lot more background and tutorial material.
  293.  
  294. The two issues with deciding to go with the new books are:
  295.  
  296. - - They aren't all out, yet.
  297.  
  298. - - They'll cost a lot more than IM I-VI. The three volumes that you mention run
  299. $78 in the US, so figure about $300-400 for the lot (IM I-VI comes to about
  300. $200). Of course, there may be a discount if you get all of them at once.
  301.  
  302. You also might want to consider having to deal with a new set of errors and
  303. typos. For those of us who have gotten well used to the old IM's and know where
  304. all the errors are, it may be disconcerting to have to deal with a new set.
  305. Hopefully, there won't be that many (as a technical reviewer for them, I
  306. personally guarantee absolutely no errors in Files, Processes, or Memory  :-) ).
  307. For people who haven't dealt with IM before, this won't be as much of a problem.
  308.  
  309. - --
  310. Keith Rollin
  311. Phantom Programmer
  312. Taligent, Inc.
  313.  
  314. +++++++++++++++++++++++++++
  315.  
  316. From: sro@media.mit.edu (Shawn O'Donnell)
  317. Date: 26 Aug 92 20:40:52 GMT
  318. Organization: M.I.T. Media Laboratory
  319.  
  320. >  Do I STILL need to get IM v1 (with references to 128k MACs and LISA)
  321. >  or should I get one or all of the New books??
  322.  
  323. Depends on who's paying. And on how long you can wait for the 15-20
  324. volumes that make up the rest of the new series.  But mostly on who's
  325. paying.
  326.  
  327. +++++++++++++++++++++++++++
  328.  
  329. From: reynhout@cs.uri.edu (Andrew Reynhout)
  330. Organization: University of Rhode Island, Computer Science Dept.
  331. Date: Wed, 2 Sep 1992 22:19:18 GMT
  332.  
  333. In article <BtLxGB.Hp0@taligent.com> keith@taligent.com (Keith Rollin) writes:
  334. >If you can wait (and have the bucks), I'd suggest getting the new books. As
  335. >you've seen, there are three now, and probably about 12 more in the wings. The
  336. >whole new suite is intended to replace the old IM I-VI, as well as many of the
  337. >technotes and sample code that DTS puts out. They are chock full of samples,
  338. >and include a lot more background and tutorial material.
  339.  
  340.    As an aside, are the code examples in C this time?  
  341.  
  342.    Andrew
  343.  
  344. - -- 
  345.    Andrew <reynhout@cs.uri.edu>    "If you remind me of my dog,
  346.                                     we'll probably get along"  -jane siberry
  347.    meow
  348.  
  349. +++++++++++++++++++++++++++
  350.  
  351. From: Joe.Francis@dartmouth.edu (Joe Francis)
  352. Date: 3 Sep 92 21:01:06 GMT
  353. Organization: Dartmouth College, Hanover, NH
  354.  
  355. In article <1992Sep2.221918.7093@cs.uri.edu>
  356. reynhout@cs.uri.edu (Andrew Reynhout) writes:
  357.  
  358. >As an aside, are the code examples [in the new IM series] in C this time?  
  359.  
  360. No, still Pascal.  However, the "Summary" at chapter ends where they
  361. list constants, data types, procedures, etc, now has *3* sections:
  362. Pascal, C, and Assembly.
  363.  
  364. ---------------------------
  365.  
  366. From: tim.meade%theweb@meaddata.com (Tim Meade)
  367. Subject: STUFFIT FORMAT
  368. Date: 29 Aug 92 10:32:00 GMT
  369. Organization: The Web BBS 1-513-436-9011 6 Lines 1200 News groups 50,000 files!
  370.  
  371. I am in need of the Stuffit or Unstuffit format. Is this in the public
  372. domain?  I want to do a conversion program and would like to be able to
  373. directly handle these files.  Any help would be apprecitive.
  374.  
  375. Please email me at tim.meade%theweb@meaddata.com
  376.  
  377.  
  378.                 thanks....Tim
  379.                                                                                                   
  380.  
  381. +++++++++++++++++++++++++++
  382.  
  383. From: sefhelp@tamuts.tamu.edu (Steve Fuller)
  384. Date: 30 Aug 92 06:03:53 GMT
  385. Organization: Texas A&M University, College Station
  386.  
  387. In article <5121.1243.uupcb@meaddata.com> tim.meade%theweb@meaddata.com (Tim Meade) writes:
  388. >I am in need of the Stuffit or Unstuffit format. Is this in the public
  389. >domain?  I want to do a conversion program and would like to be able to
  390. >directly handle these files.  Any help would be apprecitive.
  391. >
  392.  
  393. Not much chance of obtaining the new 3.0 format. HOWEVER, SD (and SL?) support
  394. ' a large number of Apple events'. Contact Aladdin for details.
  395. (408) 761-6200 or ALADDIN@Applelink
  396.  
  397. If Leonard is reading, perhaps he could provide more info. Like:
  398. Can applications call the StuffIt Engine? or must the use the SD App?
  399. Can the free UnStuffIt handle Apple Events? or be externally scripted?
  400.  
  401. Steve Fuller
  402. sef3179@tamsun.tamu.edu
  403.  
  404. +++++++++++++++++++++++++++
  405.  
  406. From: leonardr@ccs.itd.umich.edu
  407. Organization: Campus Computing Sites, University of Michigan-Ann Arbor
  408. Date: Tue, 1 Sep 1992 05:30:37 GMT
  409.  
  410. In article <1992Aug30.060353.4783@tamsun.tamu.edu> sefhelp@tamuts.tamu.edu (Steve Fuller) writes:
  411. >In article <5121.1243.uupcb@meaddata.com> tim.meade%theweb@meaddata.com (Tim Meade) writes:
  412. >>I am in need of the Stuffit or Unstuffit format. Is this in the public
  413. >>domain?  I want to do a conversion program and would like to be able to
  414. >>directly handle these files.  Any help would be apprecitive.
  415. >>
  416. >
  417. >Not much chance of obtaining the new 3.0 format. HOWEVER, SD (and SL?) support
  418. >' a large number of Apple events'. Contact Aladdin for details.
  419. >(408) 761-6200 or ALADDIN@Applelink
  420. >
  421.     Actually we license the format information to "needy" people, we also
  422. license the StuffIt Engine for inclusion in products that wish to provide
  423. stuffing/unstuffing capabilities. You want to call Aladdin and ask to speak
  424. to licensing.
  425.  
  426. >If Leonard is reading, perhaps he could provide more info. Like:
  427. >Can applications call the StuffIt Engine? or must the use the SD App?
  428. >Can the free UnStuffIt handle Apple Events? or be externally scripted?
  429. >
  430.     The StuffIt Engine is still available as part of the StuffIT Deluxe
  431. and StuffIt SpaceSaver packages, and (as mentioned above) can also be 
  432. licensed for direct inclusion in your own applications.  Also, all of
  433. our application products (Lite, Deluxe, Expander, UnStuffIt, etc.) are all
  434. Apple event aware and include an 'aete' resource (as per the OSA guidelines)
  435. for describing the supported events.  
  436.  
  437. - -- 
  438. - -----------------------------------------------------------------------
  439. Leonard Rosenthol          Internet: leonardr@ccs.itd.umich.edu
  440. Director of Advanced Technology   AppleLink: MACgician
  441. Aladdin Systems, inc.          GEnie:     MACgician
  442.  
  443. +++++++++++++++++++++++++++
  444.  
  445. From: jtgorman@cs.arizona.edu (J. Taggart Gorman)
  446. Date: 1 Sep 92 07:35:42 GMT
  447. Organization: Organization?  We don't need no steenking organization!
  448.  
  449.  
  450. In article <1992Sep1.053037.39@terminator.cc.umich.edu>,
  451. Citizen leonardr@ccs.itd.umich.edu writes :
  452. >    The StuffIt Engine is still available as part of the StuffIT Deluxe
  453. >and StuffIt SpaceSaver packages, and (as mentioned above) can also be 
  454. >licensed for direct inclusion in your own applications.  Also, all of
  455. >our application products (Lite, Deluxe, Expander, UnStuffIt, etc.) are all
  456. >Apple event aware and include an 'aete' resource (as per the OSA guidelines)
  457.  
  458.   This message is not necessarily aimed at Leonard.
  459.  
  460.   How does one read the "aete" resource?  With a template, right?  If so,
  461. where can I find the necessary template?  My ResEdit doesn't have it (I have to
  462. dredge thru the resource in straight hex/char, ick!), and I don't recall seeing
  463. it at any ftp site?  Is it in a league with BalloonWriter?  (Ie, only available
  464. from ADPA?)
  465.  
  466.  Thanks.
  467.  
  468. |--------------------------------|    "If you were happy all of your life,
  469. |      J. Taggart Gorman Jr.     |     you wouldn't be human - you'd be a
  470. | jtgorman@caslon.cs.arizona.edu |     game show host."
  471. |--------------------------------|             Winona Ryder, in _Heathers_
  472.  
  473. +++++++++++++++++++++++++++
  474.  
  475. From: Glen.Stewart@f175.n2240.z1.ieee.org (Glen Stewart)
  476. Date: 31 Aug 92 04:06:57 GMT
  477. Organization: FidoNet node 1:2240/175 - The Associati, Grand Blanc MI
  478.  
  479. I have a couple programs here that examine StuffIt files.  One contains Pascal 
  480. source code.  Perhaps one of them may help.  If so, feel free to call the BBS.
  481.  
  482.  
  483. - --  
  484. =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  485.  Glen Stewart - Internet: Glen.Stewart@f175.n2240.z1.ieee.org
  486.  
  487. ---------------------------
  488.  
  489. From: landwebe@math.rutgers.edu (Peter Landweber)
  490. Subject: Problem writing INIT/cdev
  491. Date: 3 Sep 92 05:53:43 GMT
  492. Organization: Rutgers Univ., New Brunswick, N.J.
  493.  
  494.  
  495.  
  496.      I am working on an INIT/cdev combination to be used under System
  497. 7, and I've run into a problem.
  498.      At startup time, the INIT moves its resource map after the system
  499. resource map in the linked list, and it patches CloseResFile() to
  500. ignore the file.  The result is that my file stays open, and its
  501. resources are always available.  This is similar to what Suitcase II
  502. does with font suitcases.  So far everything has gone extremely well 
  503. using this technique.
  504.      Now, I'm trying to add a "cdev".  The problem is that when the
  505. finder opens up my file as a Control Panel, it expects my file's
  506. resource map to be the first in the linked list.  Since the resource
  507. map is actually at the end of the linked list, the finder crashes.
  508.  
  509. So, my questions are:
  510. 1)  Is there a way for the Finder to open up a Control Panel if the
  511. file is already open, and its resource map is not at the front of the
  512. linked list?
  513. 2)  Is there a way to open a file twice, with two separate resource
  514. maps?  That way, I could still have one resource map linked after the
  515. system resource map, and the other at the front of the linked list.
  516. One of the maps could be read-only if necessary.
  517.  
  518. Any suggestions, answers, or solutions would be greatly appreciated.
  519.  
  520. - -- Greg Landweber  (landwebe@math.rutgers.edu)
  521.  
  522. +++++++++++++++++++++++++++
  523.  
  524. From: keith@taligent.com (Keith Rollin)
  525. Organization: Taligent
  526. Date: Thu, 3 Sep 1992 20:08:55 GMT
  527.  
  528. In article <Sep.3.01.53.43.1992.13837@math.rutgers.edu>,
  529. landwebe@math.rutgers.edu (Peter Landweber) writes:
  530. >      I am working on an INIT/cdev combination to be used under System
  531. > 7, and I've run into a problem.
  532. >      At startup time, the INIT moves its resource map after the system
  533. > resource map in the linked list, and it patches CloseResFile() to
  534. > ignore the file.  The result is that my file stays open, and its
  535. > resources are always available.  This is similar to what Suitcase II
  536. > does with font suitcases.  So far everything has gone extremely well 
  537. > using this technique.
  538. >      Now, I'm trying to add a "cdev".  The problem is that when the
  539. > finder opens up my file as a Control Panel, it expects my file's
  540. > resource map to be the first in the linked list.  Since the resource
  541. > map is actually at the end of the linked list, the finder crashes.
  542. > So, my questions are:
  543. > 1)  Is there a way for the Finder to open up a Control Panel if the
  544. > file is already open, and its resource map is not at the front of the
  545. > linked list?
  546. > 2)  Is there a way to open a file twice, with two separate resource
  547. > maps?  That way, I could still have one resource map linked after the
  548. > system resource map, and the other at the front of the linked list.
  549. > One of the maps could be read-only if necessary.
  550.  
  551. I have an INIT/cdev that does the same thing. However, it takes a little
  552. different approach than yours, and it seems to work.
  553.  
  554. First, I don't patch CloseResFile() to keep my file open. Instead, at INIT time,
  555. I install my code, remember the file I came from, and patch InitAllPacks(). I
  556. remember my file of origin with the following routine.
  557.  
  558.  
  559. static void    RememberMe()
  560. {
  561.     FCBPBRec    pb;
  562.     OSErr        err;
  563.  
  564.     pb.ioCompletion = nil;
  565.     pb.ioNamePtr = gOurName;
  566.     pb.ioVRefNum = 0;
  567.     pb.ioRefNum = CurResFile();
  568.     pb.ioFCBIndx = 0;
  569.     
  570.     err = PBGetFCBInfoSync(&pb);
  571.     
  572.     gOurVRefNum = pb.ioFCBVRefNum;
  573.     gOurDirID = pb.ioFCBParID;
  574. }
  575.  
  576.  
  577. I patch InitAllPacks() so that I can re-open my resource fork just before the
  578. first application is run:
  579.  
  580.  
  581. static pascal void    MyInitAllPacks(void)
  582. {
  583.     SetUpA4();
  584.     
  585.     oldInitAllPacks();
  586.     
  587.     if (gMyRefNum == 0)
  588.         OpenAndAddMe();
  589.         
  590.     RestoreA4();
  591. }
  592.  
  593.  
  594. OpenAndAddMe() opens the resource fork and shuffles it behind the System file:
  595.  
  596.  
  597. typedef struct ResourceMap{
  598.     long        dataOffset;
  599.     long        mapOffset;
  600.     long        dataLength;
  601.     long        mapLength;
  602.     struct ResourceMap    **nextMap;
  603.     short        refNum;
  604.     short        attributes;
  605.     short        typesOffset;
  606.     short        namesOffset;
  607. } ResourceMap, *ResMapPtr, **ResMapHandle;
  608.  
  609. static void    OpenAndAddMe()
  610. {
  611.     THz                currentZone;
  612.  
  613.     short            oldFile;
  614.     short            refNum;
  615.     ResMapHandle    current = nil;
  616.     ResMapHandle    previous = nil;
  617.     ResMapHandle    ourParent = nil;
  618.     ResMapHandle    us = nil;
  619.     ResMapHandle    system = nil;
  620.     
  621.     currentZone = GetZone();
  622.     SetZone(SystemZone());
  623.  
  624.     oldFile = CurResFile();
  625.     refNum = InlineHOpenResFile(gOurVRefNum, gOurDirID, gOurName, fsRdPerm);
  626.     UseResFile(oldFile);
  627.     
  628.     if (refNum != -1) {
  629.  
  630.         current = (ResMapHandle) TopMapHndl;
  631.         
  632.         // First, find us (we should be on top)
  633.  
  634.         while ((current != nil) && ((**current).refNum != refNum)) {
  635.             previous = current;
  636.             current = (**current).nextMap;
  637.         }
  638.         if (current != nil) {
  639.             ourParent = previous;
  640.             us = current;
  641.         }
  642.         
  643.         // Second, find the System
  644.         
  645.         system = (ResMapHandle) SysMapHndl;
  646.         
  647.         if ((us == nil) || (system == nil)) {
  648.             CloseResFile(refNum);
  649.         } else {
  650.             if (ourParent != system) {
  651.             
  652.             //
  653.             // Be sure to perform all these steps so that the
  654.             // resource chain is never inconsistant or circular.
  655.             // If that happens, debuggers like TMON will detonate.
  656.             //
  657.                 if ((ResMapHandle) TopMapHndl == us)
  658.                     TopMapHndl = (void*) (**us).nextMap;
  659.                 if (ourParent)
  660.                     (**ourParent).nextMap = (**us).nextMap;
  661.                 (**us).nextMap = (**system).nextMap;
  662.                 (**system).nextMap = us;
  663.             }
  664.             gMyRefNum = refNum;
  665.         }
  666.     }
  667.     SetZone(currentZone);
  668. }
  669.  
  670. I've checked the resource chain with this setup, and my INIT/cdev file appears
  671. to get opened twice when the cdev is opened.
  672.  
  673. Hope this helps,
  674.  
  675. - --
  676. Keith Rollin
  677. Phantom Programmer
  678. Taligent, Inc.
  679.  
  680.  
  681. ---------------------------
  682.  
  683. From: mac@coos.dartmouth.edu (Alex Colvin)
  684. Subject: A/ROSE
  685. Date: 3 Sep 92 20:12:12 GMT
  686. Organization: Dartmouth College, Hanover, NH
  687.  
  688. I'm looking for a realtime operating system to run on embedded 680x0s.
  689. I'm using a macintosh as a development platform.
  690. Someone mentioned A/ROSE as a possibility. I can't find anything
  691. about it.
  692.         Is it supported?
  693.         Is it supported by MPW?
  694.         Does it run only in a nubus slot on a macintosh, or can it
  695.         stand alone?
  696.     Is it any use?
  697.         Is there someone I can call to get details?
  698.  
  699.                 Alex Colvin
  700.                 603/643-7309
  701.                 mac@coos.dartmouth.edu
  702.  
  703. +++++++++++++++++++++++++++
  704.  
  705. From: rkn@Apple.COM (Richard K. Nordin)
  706. Date: 4 Sep 92 04:20:03 GMT
  707. Organization: Cybernetic Arts
  708.  
  709. The A/ROSE Software Kit is available from APDA (US 800-282-2732, Int'l
  710. 408 562-3910).
  711.  
  712. I could answer your other questions, but I shouldn't. But, if a
  713. real Apple person doesn't answer them, I'll do some harrassing
  714. on your behalf.
  715. - -- 
  716.  
  717. Hud Nordin
  718. Cybernetic Arts                rkn@apple.com
  719. Post Office Box 2066           Telephone: 408.248.0377
  720. Sunnyvale, California 94087    Facsimile: 408.248.0416
  721.  
  722. +++++++++++++++++++++++++++
  723.  
  724. From: arnold@i81s15.ira.uka.de (Arnold Niedermaier)
  725. Date: 8 Sep 1992 08:51:50 GMT
  726. Organization: University of Karlsruhe, FRG
  727.  
  728.  
  729. In article <1992Sep3.201212.22863@dartvax.dartmouth.edu>, mac@coos.dartmouth.edu (Alex Colvin) writes:
  730. |> I'm looking for a realtime operating system to run on embedded 680x0s.
  731. |> I'm using a macintosh as a development platform.
  732. |> Someone mentioned A/ROSE as a possibility. I can't find anything
  733. |> about it.
  734. |>         Is it supported?
  735. |>         Is it supported by MPW?
  736. |>         Does it run only in a nubus slot on a macintosh, or can it
  737. |>         stand alone?
  738. |>     Is it any use?
  739. |>         Is there someone I can call to get details?
  740. |> 
  741. |>                 Alex Colvin
  742. |>                 603/643-7309
  743. |>                 mac@coos.dartmouth.edu
  744.  
  745. - --
  746. We are using A/ROSE the Apple/Realtime Operating System Environment in our
  747. macintosh laboratory at the institute for computer design and fault tolerance.
  748. In our configuration A/ROSE runs on Serial NB MCP cards plugged in nubus slots
  749. on macintosh computers. These cards are connected with Apple V24/RS232 cables and
  750. form a distributed system. 
  751. We also use MPW as a development environment.platform. In order to run 
  752. the programs under A/ROSE you have to link some spezial libraries.
  753. When we run a distributed application on the cards we use the Macs as
  754. I/O devices to monitor and control the programflow. Our main interests are
  755. to examine fault-tolerant mechanisms and fault-tolerant protocols. 
  756. Therefore we have developed a communication kernel which provides communication
  757. promitives and a fault injection tool to trigger particular fault situations.
  758. Until now we have implemented and tested several fault-tolerant protocols 
  759. on this system. 
  760. Our expierence with A/ROSE is the following:
  761.     - the programs have to be implemented in C or assembler
  762.     - there is no support for floating point operations 
  763. A/ROSE together with the Serial NB Card satisfies our application requirements
  764. and we are going to use it in more areas.
  765.  
  766. ******************************************************************************
  767. Arnold Niedermaier                               *   Tel.:   49-721-608-3910
  768. Universitaet Karlsruhe                           *   Fax.:   49-721-370455
  769. Inst. fuer Rechnerentwurf und Fehlertoleranz     *   E-Mail: arnold@ira.uka.de
  770. Postfach 69 80                                   *   
  771. W-7500 Karlsruhe 1 Germany                       *
  772.  
  773. ---------------------------
  774.  
  775. From: agoates@nyx.cs.du.edu (Alan Goates)
  776. Subject: Best text compression?
  777. Organization: University of Denver, Dept. of Math & Comp. Sci.
  778. Date: Thu, 3 Sep 92 21:45:18 GMT
  779.  
  780.  
  781.  
  782. First, thanks to everyone who answered my Notification Manager question.
  783. (I didn't have the latest tech notes yet)
  784. Second, does anyone know what the best published (Public Domain) algorithm is
  785. for compressing text. And does anyone know where I could get my hands on examplesource code for said algorithm (The only one I've seen is Lempel-Ziv).
  786. Thanks in advance,
  787. AL
  788.  
  789. +++++++++++++++++++++++++++
  790.  
  791. From: anderson@Apple.COM (Clark Anderson)
  792. Date: 4 Sep 92 03:54:08 GMT
  793. Organization: Apple Computer Inc., Cupertino, CA
  794.  
  795. agoates@nyx.cs.du.edu (Alan Goates) writes:
  796.  
  797.  
  798.  
  799. >First, thanks to everyone who answered my Notification Manager question.
  800. >(I didn't have the latest tech notes yet)
  801. >Second, does anyone know what the best published (Public Domain) algorithm is
  802. >for compressing text. And does anyone know where I could get my hands on examplesource code for said algorithm (The only one I've seen is Lempel-Ziv).
  803. >Thanks in advance,
  804. > AL
  805.  
  806. I have gotten pretty good compression on text using
  807. a Huffman algorithm. It's pretty easy to implement,
  808. any standard book on compression schemes should
  809. have it.
  810.                            --clark
  811. - ----------------------------------------------------------
  812. Clark Anderson                 BellNet: 408-974-4593
  813. Apple Computer, Inc.         AppleLink: C.ANDERSON
  814.                               InterNet: anderson@apple.com
  815. I speak only for myself...
  816. - ----------------------------------------------------------
  817.  
  818.  
  819. +++++++++++++++++++++++++++
  820.  
  821. From: keith@taligent.com (Keith Rollin)
  822. Organization: Taligent
  823. Date: Fri, 4 Sep 1992 07:07:32 GMT
  824.  
  825. In article <71986@apple.Apple.COM>, anderson@Apple.COM (Clark Anderson) writes:
  826. > agoates@nyx.cs.du.edu (Alan Goates) writes:
  827. > >Second, does anyone know what the best published (Public Domain) algorithm is
  828. > >for compressing text. And does anyone know where I could get my hands on 
  829. > >examplesource code for said algorithm (The only one I've seen is Lempel-Ziv).
  830. > I have gotten pretty good compression on text using
  831. > a Huffman algorithm. It's pretty easy to implement,
  832. > any standard book on compression schemes should
  833. > have it.
  834.  
  835. I've never tried this myself, but someone once told me that you can get really
  836. good compression if you use a Huffman algorithm applied at the word level.
  837. Instead of counting and ranking all of the letters in the document, count the
  838. distinct words and treat each one like a single letter. This means that oft used
  839. words like "the" or "MicroSoftWord5.0Sucks" will compress down to 3 or 4 bits
  840. for the entire word.
  841.  
  842. - --
  843. Keith Rollin
  844. Phantom Programmer
  845. Taligent, Inc.
  846.  
  847.  
  848. +++++++++++++++++++++++++++
  849.  
  850. From: ksand@apple.com (Kent Sandvik)
  851. Date: 5 Sep 92 01:42:30 GMT
  852. Organization: Apple
  853.  
  854. In article <71986@apple.Apple.COM>, anderson@Apple.COM (Clark Anderson)
  855. wrote:
  856. > I have gotten pretty good compression on text using
  857. > a Huffman algorithm. It's pretty easy to implement,
  858. > any standard book on compression schemes should
  859. > have it.
  860.  
  861. For instance the new "Algorithsm in C++" by Sedgewick has a code
  862. snippet showing how it's done. Seems more and more authors are making
  863. big bucks on rewriting their books with "C++" in the title.
  864.  
  865. Kent Sandvik/DTS
  866.  
  867. +++++++++++++++++++++++++++
  868.  
  869. From: d88-jwa@dront.nada.kth.se (Jon W{tte)
  870. Date: 7 Sep 92 10:19:45 GMT
  871. Organization: Royal Institute of Technology, Stockholm, Sweden
  872.  
  873. > agoates@nyx.cs.du.edu (Alan Goates) writes:
  874.  
  875.    Second, does anyone know what the best published (Public Domain) algorithm is
  876.    for compressing text. And does anyone know where I could get my hands on example
  877.    source code for said algorithm (The only one I've seen is Lempel-Ziv).
  878.  
  879. Lempel-Ziv isn't too bad (actually, that's two whole familys of
  880. algorithms)
  881.  
  882. Source avaialble for the macintosh is LZRW-1b which is a high-
  883. speed, LZ-77 derivative.
  884.  
  885. "Yabba" is an LZ-78 relative that also is in the public domain.
  886.  
  887. - -- 
  888. Jon W{tte, h+@nada.kth.se, Sweden, Phone +46-8-107069
  889.  
  890. Help eradicate FIDO-Net <-> Usenet gateways in our time!
  891.  
  892. +++++++++++++++++++++++++++
  893.  
  894. From: stauffer@cc.swarthmore.edu (Glenn Stauffer)
  895. Date: 9 Sep 92 00:31:45 GMT
  896. Organization: Swarthmore College Computing Center
  897.  
  898. In article <D88-JWA.92Sep7111945@dront.nada.kth.se> Jon W{tte,
  899. d88-jwa@dront.nada.kth.se writes:
  900. >Source avaialble for the macintosh is LZRW-1b which is a high-
  901. >speed, LZ-77 derivative.
  902. >
  903. >"Yabba" is an LZ-78 relative that also is in the public domain.
  904. >
  905.  
  906. Does anyone have the address of an FTP site for the LZ* source?
  907.  
  908. ---------------------------
  909.  
  910. From: mxmora@unix.sri.com (Matthew Xavier Mora)
  911. Subject: How do you launch a Control Panel?
  912. Date: 3 Sep 92 22:10:29 GMT
  913. Organization: SRI International
  914.  
  915. How do you launch a control panel under system 7? LaunchApplication
  916. doesn't seem to work. LaunchDeskAccessory doesn't work either. (I know but
  917. I tried it anyway). Is OpenDeskAcc my only hope?
  918.  
  919. Has anybody done this? I can't post an event to the finder because it might
  920. be closed or busy coping a file.
  921.  
  922. Thanks
  923.  
  924. Matt
  925.  
  926. +++++++++++++++++++++++++++
  927.  
  928. From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
  929. Date: 5 Sep 92 05:39:44 GMT
  930. Organization: University of Waikato, Hamilton, New Zealand
  931.  
  932. In article <mxmora-030992150746@css-mac1.sri.com>, mxmora@unix.sri.com (Matthew Xavier Mora) writes:
  933. > How do you launch a control panel under system 7? LaunchApplication
  934. > doesn't seem to work. LaunchDeskAccessory doesn't work either. (I know but
  935. > I tried it anyway). Is OpenDeskAcc my only hope?
  936. >
  937. > Has anybody done this? I can't post an event to the finder because it might
  938. > be closed or busy coping a file.
  939.  
  940. Control panels don't run as separate processes with Finder 7. They run within
  941. the Finder's process context. That's why there is no Process Manager call for
  942. opening them; you really have to do it by posting an event to the Finder.
  943.  
  944. My Default Application control panel relies on this: that's how it's able to
  945. patch the running Finder without installing INITs or any such black magic.
  946.  
  947. Lawrence D'Oliveiro                       fone: +64-7-856-2889
  948. Computer Services Dept                     fax: +64-7-838-4066
  949. University of Waikato            electric mail: ldo@waikato.ac.nz
  950. Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
  951. The Internet protocol standardization process will now consist of three
  952. stages: TRFCs (Tentative Requests for Comment), FRFCs (Firm Requests for
  953. Comment), and DFCs (Demands for Comment).
  954.  
  955. ---------------------------
  956.  
  957. From: brad@vedge.UUCP (Brad Fowlow)
  958. Subject: Top byte of 24-bit offscreen gworld?
  959. Date: 3 Sep 92 18:51:40 GMT
  960. Organization: Visual Edge Software, St. Laurent, Quebec
  961.  
  962. Can anyone say how quickly or terribly things might
  963. go awry if I try to keep some extra info in the top 8 bits
  964. of the pixel data of a 24-bit offscreen gworld?
  965.  
  966. That byte is awfully tempting as a place for alpha stuff.
  967. And for the moment I'm not too concerned with how the code
  968. will react under system 12; I just don't want sneaking 
  969. randomness to show up next week. 
  970. Have I missed something in IM6 that unequivocally rules
  971. this out, or permits it?  Has anyone else been similiarly tempted?
  972.  
  973.  
  974. - -- 
  975. - -------------------------------------------------------------
  976.  Brad Fowlow   brad@vedge.com     Visual Edge Software Limited  
  977.  
  978. +++++++++++++++++++++++++++
  979.  
  980. From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
  981. Date: 4 Sep 92 17:47:49 +1200
  982. Organization: University of Waikato, Hamilton, New Zealand
  983.  
  984. In article <28628@vedge.UUCP>, brad@vedge.UUCP (Brad Fowlow) writes:
  985. > Can anyone say how quickly or terribly things might
  986. > go awry if I try to keep some extra info in the top 8 bits
  987. > of the pixel data of a 24-bit offscreen gworld?
  988. >
  989. > That byte is awfully tempting as a place for alpha stuff.
  990. > And for the moment I'm not too concerned with how the code
  991. > will react under system 12; I just don't want sneaking
  992. > randomness to show up next week.
  993. > Have I missed something in IM6 that unequivocally rules
  994. > this out, or permits it?  Has anyone else been similiarly tempted?
  995.  
  996. I get the feeling from IM6 that there is no great crime in using the extra
  997. byte for your own purposes. Just bear in mind that most QuickDraw drawing calls
  998. clear that byte in pixels that they modify; I think it's only CopyBits and
  999. its relatives that would preserve that byte, and then probably not in all
  1000. circumstances.
  1001.  
  1002. Basically Apple isn't interested in adding future alpha channel support or
  1003. making any future use of that byte. Or so I gather. Remember, at least one
  1004. of Apple's video cards doesn't even have RAM allocated to store that byte!
  1005.  
  1006. And, let's face it--what can you do with alpha channels, that you can't do
  1007. using "blend" mode with CopyBits, and blend mask pixmaps with
  1008. CopyMask/CopyDeepMask? These existing QuickDraw blending facilities are so much
  1009. more powerful...
  1010.  
  1011. Lawrence D'Oliveiro                       fone: +64-7-856-2889
  1012. Computer Services Dept                     fax: +64-7-838-4066
  1013. University of Waikato            electric mail: ldo@waikato.ac.nz
  1014. Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
  1015. Q: Why do dogs make poor astronauts?
  1016. A: They keep sticking their head out the window and burning up on re-entry.
  1017.  
  1018. +++++++++++++++++++++++++++
  1019.  
  1020. From: Jim Cook <J.Cook@ENS.Prime.COM>
  1021. Organization: Prime Computer, Inc.
  1022. Date: Fri, 4 Sep 1992 18:10:47 GMT
  1023.  
  1024. In article <28628@vedge.UUCP> brad@vedge.com (Brad Fowlow) writes:
  1025. >Can anyone say how quickly or terribly things might
  1026. >go awry if I try to keep some extra info in the top 8 bits
  1027. >of the pixel data of a 24-bit offscreen gworld?
  1028. >
  1029. >That byte is awfully tempting as a place for alpha stuff.
  1030. >And for the moment I'm not too concerned with how the code
  1031. >will react under system 12; I just don't want sneaking 
  1032. >randomness to show up next week. 
  1033. >Have I missed something in IM6 that unequivocally rules
  1034. >this out, or permits it?  Has anyone else been similiarly tempted?
  1035.  
  1036. The only think I know is that you better check the spec's on your video board.
  1037. Some video boards implement 32 bits per pixel and ignore the high 8 bits and
  1038. some board don't have the memory there to save money.  Check your board and
  1039. the boards of any other Macs you want to run on.
  1040.  
  1041. Since I don't know many video board vendors that make use of the fourth byte
  1042. in 32-bit (24-bit) color mode (TruVision was one vendor), I don't know how
  1043. rigorous Apple has been in testing to see that byte makes it out to the 
  1044. video board complete and unchanged.  On the other hand, I don't have any
  1045. evidence that it won't - just idle curiosity.
  1046.  
  1047. Jim
  1048.  
  1049.  
  1050. +++++++++++++++++++++++++++
  1051.  
  1052. From: mkelly@sisters.cs.uoregon.edu (Michael A. Kelly)
  1053. Organization: University of Oregon Computer and Information Sciences Dept.
  1054. Date: Fri, 4 Sep 1992 20:17:11 GMT
  1055.  
  1056. In article <1992Sep4.181047.16762@primerd.prime.com> <J.Cook@ENS.Prime.COM> writes:
  1057. >In article <28628@vedge.UUCP> brad@vedge.com (Brad Fowlow) writes:
  1058. >>Can anyone say how quickly or terribly things might
  1059. >>go awry if I try to keep some extra info in the top 8 bits
  1060. >>of the pixel data of a 24-bit offscreen gworld?
  1061. >>
  1062. >>That byte is awfully tempting as a place for alpha stuff.
  1063. >>And for the moment I'm not too concerned with how the code
  1064. >>will react under system 12; I just don't want sneaking 
  1065. >>randomness to show up next week. 
  1066. >>Have I missed something in IM6 that unequivocally rules
  1067. >>this out, or permits it?  Has anyone else been similiarly tempted?
  1068. >
  1069. >The only think I know is that you better check the spec's on your video board.
  1070. >Some video boards implement 32 bits per pixel and ignore the high 8 bits and
  1071. >some board don't have the memory there to save money.  Check your board and
  1072. >the boards of any other Macs you want to run on.
  1073.  
  1074. If the extra memory isn't available, the card should take care of that
  1075. itself.  Since there's no such thing as a 24-bit GWorld, those cards must
  1076. be taking the extra byte into account.
  1077.  
  1078. If a card does have the extra memory, and it uses that memory internally,
  1079. it should still be masking off the extra byte in a 32-bit GWorld.  If the
  1080. card has the memory but doesn't use it, it doesn't matter whether or not
  1081. it copies the extra byte.
  1082.  
  1083. This is all assuming you're using QuickDraw.
  1084.  
  1085. I haven't tested this, but it _should_ work that way.  Please correct me
  1086. if I'm wrong.
  1087.  
  1088. Mike.
  1089. - -- 
  1090. _____________________________________________________________________________
  1091. Michael A. Kelly                                         University of Oregon
  1092. mkelly@cs.uoregon.edu                             Computer Science Department
  1093. _____________________________________________________________________________
  1094.  
  1095. +++++++++++++++++++++++++++
  1096.  
  1097. From: paul@taniwha.UUCP (Paul Campbell)
  1098. Date: 8 Sep 92 07:06:08 GMT
  1099. Organization: Taniwha Systems Design
  1100.  
  1101. In article <28628@vedge.UUCP> brad@vedge.com (Brad Fowlow) writes:
  1102. >Can anyone say how quickly or terribly things might
  1103. >go awry if I try to keep some extra info in the top 8 bits
  1104. >of the pixel data of a 24-bit offscreen gworld?
  1105. >
  1106. >That byte is awfully tempting as a place for alpha stuff.
  1107. >And for the moment I'm not too concerned with how the code
  1108. >will react under system 12; I just don't want sneaking 
  1109. >randomness to show up next week. 
  1110. >Have I missed something in IM6 that unequivocally rules
  1111. >this out, or permits it?  Has anyone else been similiarly tempted?
  1112.  
  1113. Well you can go ahead and put data in the top byte BUT don't expect QuickDraw
  1114. to do anything usefull with it .... despite what IM sais a later note in
  1115. Develop said recently that you should NOT depend on CopyBits preserving
  1116. that byte - even if it dows now it might not in the future - or in all
  1117. the circumstances you can test today.
  1118.  
  1119. All 24-bit cards I know of that ship today do NOT preserve the top eight
  1120. bits a pixel - but then they aren't GWorlds and you can't get usefull data
  1121. on there with out CopyBits anyway
  1122.  
  1123.     Paul
  1124.  
  1125. - -- 
  1126. Paul Campbell    UUCP: ..!mtxinu!taniwha!paul     AppleLink: CAMPBELL.P
  1127.  
  1128.        "Most American's day to day experience of 'Family Values' is found in
  1129.     brightly colored fliers from such organisations as Target and K-Mart."
  1130.  
  1131. ---------------------------
  1132.  
  1133. End of C.S.M.P. Digest
  1134. **********************
  1135.